에티버스 VMware 클라우드 스탠다드 아키텍처 가이드
CC BY 4.0
- https://creativecommons.org/licenses/by/4.0/deed.ko
편집: 에티버스 SDI사업본부
저자: 장혜천, 박하림, 우승민, 정수윤, 오예빈
표지: 백지은
VMware 및 VMware by Broadcom은 Broadcom의 등록 상표입니다. 여기에 언급된 다른 모든 제품 및 회사 이름은 각 소유자의 상표이거나 등록 상표입니다.
헌사
우리는 모두 꿈꾸는 것들을 현실로 만들기 위해 열심히 달려가고 있습니다. 하지만 그 방법은 쉽지 않을 수 있다는 것을 잘 알고 있습니다.
때로는 지식의 부족으로 잘못된 길로 들어서며, 시간의 제약에서 원하는 만큼의 성과를 보지 못할 수도 있고, 서로 다른 방향을 바라보는 이상을 최대한 조율하여 실현 가능한 목적지에 도달해야 합니다.
모든 힘든 일을 넘어 이 결과를 낼 수 있도록 전폭적인 지원과 도움을 주신 브로드컴 및 에티버스의 모든 분께 감사의 말씀을 드립니다.
— 장혜천
제사
Yesterday we obeyed kings and bent our necks before emperors. But today we kneel only to truth, follow only beauty, and obey only love.
The Vision: Reflections on the Way of the Soul
서문
문서의 목적
본 문서는 소프트웨어 정의 데이터 센터 (software-defined data center, SDDC) 및 클라우드 관리 포털 (Cloud Management Portal, CMP)를 제공하는 Broadcom의 VMware Cloud Foundation (VCF) 솔루션을 다룬다.
VCF의 설계 고려 사항을 이해한 파트너와 고객의 엔지니어에게 Orbrium Cloud Portal의 운영을 위한 포괄적인 개관 제공을 목적으로 한다.
-
사전 설계에 기반하여 Etevers Virtualization Standard (EVS) 및 Etevers VMware Cloud Standard (EVCS) 아키텍처의 SDDC 토폴로지를 구현한다.
-
EVCS 아키텍처의 SDDC 토폴로지 환경에 Orbrium을 구현한다.
프로젝트에 대해
에티버스 D&N SDI사업본부는 국내 최초의 VMware 한국 총판으로서 소프트웨어 정의 데이터 센터 솔루션 및 보안 솔루션을 공급하고 있다.
이 프로젝트는 구 VMware Korea 전인호 지사장의 리더십에서 시작하였으며, Broadcom 김정환 부사장 및 오용원 부사장이 이어받아 완료하였다.
에티버스 D&N부문 김범수 대표와 SDI사업본부 이정현 본부장은 VMware Cloud Management Business Unit 장혜천 상무를 영입하여 프로젝트의 정신적 승계하였고, 프라이빗 클라우드 서비스로서의 프레임워크 기술 구현을 시작하였다.
VMware by Broadcom의 Commercial & Partners Sales 팀 리더인 이형직 전무는 에티버스의 프로젝트를 전폭 지지 및 커머셜 티어를 위한 채널 비즈니스 강화로서 적극 추진하였으며, 한국 부사장 임원석 부사장 및 오용원 부사장은 이를 전사적 프로젝트로서 인수하고 Broadcom Customer Experience Services와 연계하여 전체 고객 만족을 위한 비즈니스 모델인 VCF Unified Experience (VUE)로 재설계하였다.
저자 서문
"클라우드" 라는 것을 단순히 기술 구현의 문제로 접근할 때, 우리는 많은 어려움을 겪게 됩니다. 근원적으로 가장 큰 어려움은 "클라우드" 라는 것의 실체와 정의가 없다는 것입니다. 많은 사람들이 클라우드를 기술적인 요소로 접근하지만, 정확히 클라우드를 정의할 단위 기술은 존재하지 않습니다.
사실상 클라우드는 하드웨어, 소프트웨어, 컴퓨팅, 네트워크, 스토리지, 운영체제, 소프트웨어, 보안, 알고리즘, API, 운영 방법론, 비즈니스 서비스 등을 서로 하나로 묶어놓은 "연동체" 개념으로 보아야 합니다.
그렇기에 단순히 몇몇 기술이나 사람으로 거대한 "연동체" 개념을 설계하고 운영하기란 쉽지 않은 일입니다.
만약 클라우드를 "연동체" 개념으로 바라본다면, 우리가 먼저 생각해 보아야 할 것들은 다음과 같을 것입니다.
-
연동을 통해 이루고자 하는 목표가 무엇인가?
-
목표를 이루기 위해 어떠한 요소들을 연동할 것인가?
-
여러 요소를 어떠한 방법으로 연동할 것인가?
사실 이 부분에서 VMware는 물리적인 많은 부분을 논리적인 요소로 바꿔주며, 여러 인프라 기술 간에 효과적인 연동을 통해 많은 답을 주고 있습니다.
그렇기에 많은 사람들이 VMware 제품을 구입하면 클라우드를 구축한다는 오해가 만연한 것도 사실입니다.
무수히 수행되었던 클라우드 구축 목표에서 VMware는 클라우드를 구축하기 위한 훌륭한 재료일 수 있었으나, 최종적으로 앞선 질문에 대한 결론이 부족하여 원하던 만큼의 성과가 이루어진 사례가 소수인 점도 사실입니다.
-
VUE (VMware Unified Experience)는 VMware 생태계를 활용하여 최종적으로 위의 질문에 답하기 위한 최종적인 방법들을 제공합니다.
-
EVCS (Etevers VMware Cloud Standards)를 통해 VMware 생태계를 활용하여 표준 논리 구성을 완성하고,
-
BVP (Broadcom Value Pack)를 통해 표준 클라우드 운영 방안을 수행하고,
-
Orbrium을 통해 최종 완성된 클라우드 경험을 제공합니다.
VUE를 통하여 많은 분이 클라우드 경험을 완성하기를 소원합니다.
— 장혜천
1. 소개
VCF는 VMware by Broadcom의 SDDC 제품을 모두 모아 소프트웨어 정의 인프라스트럭처 중앙 관리 소프트웨어인 SDDC Manager를 통해 프라이빗 클라우드 인프라스트럭처를 구현하는 솔루션이다.
VCF Unified Experience는 제조사-총판-리셀러의 상생협력 체제로서, Broadcom의 업무 기술 방법론과 절차를 표준화하여 고객 경험을 향상시키는 기술 비즈니스 모델인 상생협력 체제이다.
프라이빗 클라우드의 상용 표준화를 구현하기 위한 3종의 업무 모델을 가지고 있다.
-
Etevers VMware Cloud Standard
-
Broadcom Value Pack
-
Orbrium
1.1. EVCS
EVCS는 국내 환경 특성에 맞춘 손쉬운 VCF 표준 설계안을 제공하며, 모든 파트너의 기술 이행 표준화를 돕고자 하였다.
VCF로 구현하는 SDDC 두 인프라스트럭처 환경을 가진다.
-
지원 인프라스트럭처
-
클라우드 서비스 인프라스트럭처
1.1.1. EVCS Architecture
EVCS는 VCF의 클라우드 서비스 인프라스트럭처를 위한 아키텍처이다. Broadcom CXS의 상용 클라우드 구현 방안을 따라 BVP 및 Orbrium을 배포할 SDDC 구조이다.
1.1.2. EVS Architecture
EVS는 VCF의 지원 인프라스트럭처 환경을 위한 아키텍처이다. SDDC 및 클라우드 구현에 수반되는 전통 인프라스트럭처 시스템의 가상화 데이터 센터 구조이다.
EVS는 VMware vSphere Foundation (VVF) 솔루션[1]을 따르며, vSphere 설계는 VCF와 동일한 구성을 권한다.
| VCF 9부터 VVF 및 VCF 환경을 배포 및 라이프사이클 관리를 통합할 것으로 알려졌다. 그러므로 각 인프라스트럭처의 vSphere 환경 구성이 서로 동일한 VMware Validated Solutions 지침을 따름이 유리하다. |
필요 서비스만 살피면 지원 인프라스트럭처의 구현은 가상화 데이터 센터 여부와는 무관하나, EVS의 추종을 권장한다.
1.2. Broadcom Value Pack
BVP는 Broadcom Customer Experience Services (이하 Broadcom CXS) 조직에서 제공하는 클라우드 인프라 서비스를 위한 부가 서비스이다.
상용 클라우드 표준에 맞추어 리소스 프로비저닝을 자동화하기 위해 미리 구성된 템플릿을 제공한다. 템플릿은 6개의 기본 범주로 구성하였으며, 사용자가 다양한 사용 사례에 맞게 서비스를 빠르고 효율적으로 구성할 수 있다. 사용자는 이러한 템플릿을 활용하여 VCF 환경 전반에 인프라 구성 요소 배포를 자동화/간소화할 수 있다.[2]
-
Compute
-
Network
-
VPC
-
Access IP
-
Load Balancer
-
Segment
-
Segment Peering
-
-
Storage
-
Block Disk
-
Network File System
-
-
Security
-
Distributed Firewall
-
-
Container
-
Kubernetes Cluster
-
Kubernetes Namespace
-
-
Database
-
PostgreSQL
-
MySQL
-
1.3. Orbrium
Orbrium은 BVP의 방안에 맞춘 API 프레임워크를 기반으로 하여, 클라우드 사용성 표준화를 내세운 클라우드 이용자 포털이다.
Identity Manager와 연동한 별도의 엔터프라이즈 환경의 통합 인증 기능을 제공하며, 승인 및 권한 제어를 통한 운영 절차 확립을 제공한다.
클라우드 주문을 실현하는 마법의 구슬 orb이 있는 공간 rium을 뜻한다. 클라우드 구축과 서비스 제공을 어렵게 만들었던 다양한 요소를 Orbrium 통하여 체계성을 가지며 접근할 수 있다.
EVS 및 EVCS 아키텍처 환경에서의 사용과 Admin Proxy 구현에 대해 기술 지원을 제공한다.
1.3.1. Orbrium 연동체 개념
Admin Proxy
지원 인프라 스트럭처와 클라우드 서비스 인프라스트럭처 사이에는 웹 애플리케이션 프록시 서버가 위치한다. 클라우드 서비스 인프라스트럭처를 대상으로한 정보 노출 및 접근 통제 역할이다.
Orbrium Cloud Portal
EVS, EVCS 그리고 Admin Proxy를 포함한 연동체 역할을 하는 클라우드 사용자 포털이다.
2. 공통 인프라스트럭처
공통 인프라스트럭처는 EVCS에서 정의하는 표현이다.
지원 인프라스트럭처는 클라우드 서비스 인프라스트럭처처럼 vSphere 기반 환경을 갖출 수 있으며, 기반을 통합하여 설계 및 유지보수 업무절차를 통합한다. 이를 '공통 인프라스트럭처' 환경으로 정의한다.
공통 인프라스트럭처 환경은 언더레이 네트워크에 기반하며, 다양한 하드웨어 스택과 밀접한 업무 연관성을 갖추고 있다.
또한 사이버보안으로서 워크로드 보호 통제 계층을 고려하여 설계한다.
2.1. 네트워킹
VMware Validated Solutions에서 네트워크 서비스는 이중화를 기반으로 한다. EVCS도 이를 따른다.
| PoC 등을 위해 L3 스위치 구성으로 이중화 인식을 시킬 수 있다. |
2.1.1. 스위치 (하드웨어)
L2 스위치를 쓰는 경우, 적어도 하기의 국제 표준 프로토콜을 지원해야 한다.
-
IEEE 802.1Q (VLAN, trunking)
-
이더넷 프레임 9038 바이트 이상의 Jumbo Frame
네트워크 이중화의 경우, STP 연결 설계를 해야 한다.
-
IEEE 802.1d (STP)
-
IEEE 802.1w (RSTP)
-
IEEE 802.1s (MSTP, default)
| Beacon Probing[4]은 최후의 수단이며, 실현 및 관리에 어려움이 있다. |
2.1.2. 대역폭
네트워크 인터페이스 카드는 기본 10Gbps 이상으로 선택한다.
VCF는 10Gbps 미만 대역폭을 허용하지 않으며, 이전의 여러 1Gbps pNIC을 활용한 vSphere 기능별 트래픽 분할 방법론은 불가하다.
vSAN ESA와 같은 NVMe 기반 고속 HCI 스토리지 서비스를 구현한다면 스토리지 네트워크는 개념 증명 기준 25Gbps 이상으로 하며, 프로덕션의 경우 100Gbps를 기본으로 한다.
2.1.3. MTU
TCP/IP의 기본값인 MTU 1500 byte는 문제해결에 유연하게 대처할 수 있어야 하는 하이퍼바이저 및 관리 네트워크에 사용한다.
하이퍼바이저를 제외한 VCF 환경에서의 기본 MTU 값은 9000 바이트이다. 네트워크 스위치의 지원 사양에 따라 증감할 수 있다.
2.1.4. 라우터
L3 단계에서는 라우터의 역할과 트래픽 경로에 대한 이해를 필요로 한다.
라우터는 BGP 다이나믹 라우팅 프로토콜 사용하여 네트워크를 광고 및 재유통할 수 있어야 한다.
NSX는 BGP/OSPFv2 지원하고, 국내에서는 OSPF가 더 익숙할 수도 있겠으나, VCF의 SDDC Manager를 통한 Edge Cluster를 배포는 BGP를 사용한다.
하드웨어 (스위치/라우터)
상기 사항과 네트워크 패킷 흐름을 고려하여 적절하게 구성한다.
소프트웨어 (L3/L4/L7)
L3 이상의 언더레이 네트워크는 가상화를 통해 소프트웨어화 구현할 수 있으나, 추가 설계를 고려해야 한다.
| PoC 등의 특수한 상황에서의 네트워크 구현에 쓰일 수 있다. |
L3의 경우, 고가의 스위치 가격에서 벗어날 여지가 있으나, 박스 단위의 스로우풋 보장이 없이 유연한 운영을 전제한다. 기업 문화에 따라 적용 및 유지보수에 어려운 요소를 포함한다.
L3의 경우, 이중화를 반드시 구현한다. 게이트웨이 접근 문제 시 전체 데이터 센터 전체 장애로 번질 수 있다. 스펙이 높은 X86 서버 특성상 네트워크 박스보다 유지보수 리스크가 크다.
하이퍼바이저 단위의 망 혼용 관리 규정이 있거나, 별도의 언더레이 엣지 클러스터 구축 시의 비용 차이가 박스 장비 교체에 비해 크게 다르지 않을 수 있다.
Edge Cluster 전용의 vSphere Cluster를 별도로 운영하는 엔터프라이즈에서 고려하거나, 역으로 평시 트래픽이 높지 않은 않은 VVF 환경하에 고려할 수 있다.
가상화 소프트웨어 라우터 구성 시,
-
소프트웨어 라우터만을 위한 포트 그룹을 만든다.
-
포트 그룹은 하이퍼바이저 호환 수준인 Ephemeral (no binding) 수준으로 구성한다.
-
라우터가 트래픽을 추적 및 집계할 수 있도록 promiscuous mode를 허용한다.
-
라우터가 작성하는 트래픽에 대한 오인이 발생하지 않도록 forged transmits을 허용한다.
가상화 소프트웨어 라우터 이중화 구성 시,
-
이중화를 위한 시리얼 네트워크 포트 그룹을 만든다.
-
전통 네트워크 장비 이중화는 필연적으로 MAC 주소 위조가 발생하므로, 소프트웨어 라우터를 연결한 모든 포트 그룹에 MAC address changes를 허용한다.
| 경우에 따라서는 소프트웨어 라우터의 OS에 따라 점보 프레임을 제대로 다룰 수 있는 커널을 가졌는지 살펴야 한다. |
2.1.5. Domain Name System
지원 인프라스터럭처 및 클라우드 서비스 인프라스터럭처 양측에서 DNS 서버를 구현해야 한다.
Cross-Origin Resource Sharing (CORS) 체크는 모던 서비스 간 연결의 기본이며, 클라우드 인프라스트럭처 또한 이에 대한 준수를 요한다.
최상위 도메인과 2단계 도메인의 정의하여 그리고 Fully Qualified Domain Name (FQDN)과 Uniform Resource Identifier (URI) 사용해 통신하기 위함이다.
Open Source를 활용할 경우, 다양한 소프트웨어를 통해 직접 구현할 수 있다. 예를 들면 하기와 같다.
-
DNS: Unbound, Dnsmasq or et cetera
VMware가 지원하는 Microsoft Active Directory 사용할 경우, DNS 서버가 기본 동작한다.
-
DNS: Active Directory Domain Services
Top-level domain
최상위 도메인은 .com, .one, .network, .local과 같은 접미사 도메인이며, 용도 등을 나타내는 데 쓰인다.
조직 도메인을 고를 때는 IANA가 선언한 특수 용도 도메인 이름[5]을 피하여 고유한 접미사를 선택한다.
| .local 접미사도 RFC 규약에 의해 mDNS를 위한 용도와 목적이 있다. 자동 할당 시에 임시로 사용되는 도메인이다. 규약에 집착하는 앱의 경우, 통신에 문제가 없어도 고의로 특수 용도 도메인에 거절하여 방해하는 사례가 흔하다. 호스트에.local 사용 시, 타 서비스와의 통신에 사용하지 말 것. |
Second-level domain
2단계 도메인은 최상위 도메인 앞에 기입하며, 조직 이름 등으로 널리 쓰인다.
각 인프라스트럭처 환경의 이름에 사용한다.
Fully Qualified Domain Name
정규화 도메인 이름은 호스트 (인스턴스) 간 고유한 전체 도메인 이름이다.
FQDN은 특정 도메인으로 이동하는 트래픽을 허용하거나 거부하는 방화벽 규칙에 쓰일 수 있다.[6]
Public DNS
인터넷에 노출하는 외부 네임 서버이다. ICANN에서 제공하는 일반 최상위 도메인 (generic top-level domain, gTLD)을 사용한다.
ORG DNS
gTLD를 사용하는 조직 내부의 네임 서버이다. 조직원이 인터넷과 동일한 도메인으로 사내망을 통해 접속하여 이용함으로써 패킷이 밖으로 흐르는 요소를 막는다. 예상치 못한 부하나 패킷 감청으로부터 보안을 지키기 위한 기본 영역이다.
| 온프레미스의 경우, 외부에 서버를 노출 시키는 Web Application Firewall이 함께한다. |
ORG Internal DNS
EVS 지원 인프라스트럭처가 사용하는 조직 내부의 Admin Proxy 네임 서버이다.
클라우드 사용자는 Admin Proxy에 접근하며 계류하는 영역이다.
ORG Internal Domain에서는 Cloud System Domain의 클라우드 서비스 인프라트럭처의 아이피를 확인할 수 없으며, Reverse Proxy에서 인가한 프로토콜 및 포트를 통해 접근만 할 수 있다.
고유한 최상위 도메인 및 2단계 도메인을 서비스한다.
Cloud System DNS
EVCS 클라우드 서비스 인프라스트럭처가 사용하는 조직 네임 서버이다.
각 연결 호스트 간의 실제 모든 아이피를 서비스한다.
| VMware by Broadcom은 Planning and Preparation Workbook은 ORG Internal Domain의 2단계 도메인을 공유하여 서브도메인을 선택하도록 권하고 있다. 이는 Private CA의 중간 인증 기관 (Intermediate CA)에서 SSL 인증서를 발급하는 설계로 보인다. |
EVCS에서는 고유한 최상위 도메인 혹은 2단계 도메인으로 선택한다.
2.1.6. NTP
vCenter를 포함해 서버 간 역할에 있어 순차 오동작이 없도록 하려면 모든 서버의 시간을 동기화하여야 한다.
Open Source를 활용할 경우, 다양한 소프트웨어를 통해 직접 구현할 수 있다. 예를 들면 하기와 같다.
-
NTP: NTPD
VMware가 지원하는 Microsoft Active Directory 사용할 경우, 하기의 기능을 켜 구현할 수 있다.
-
NTP: Windows Time Services
| Microsoft Active Directory는 도메인 컨트롤러 그룹 정책을 한 번만 편집하여 기능을 켠다.[7] 이후에는 도메인 커트롤러를 만들 때마다 자동으로 NTP 서버가 동작한다. |
| NTP 서버를 가상 머신으로 구현할 경우, VMware Tools 및 Open VM Tools의 기본 기능인 호스트와의 시간 동기화 기능을 끈다.[8] |
2.2. Network Attached Storage
SDDC Manager, vCenter, NSX Manager의 구성 백업/복원을 위해 네트워크 결합 스토리지를 구현한다.
2.3. Object Storage Service
데이터베이스 정보 저장/백업/복원을 위해 오브젝트 스토리지 서비스 (OSS) 구현을 고려한다.
OSS의 구현은 선택사항이다. 현재 EVCS 환경에 OSS의 구현을 고려할 요소는 크게 두 가지이다.
-
Orbrium Cloud Portal에서의 프록시 사용
-
Data Services Manager (DSM) 사용
2.3.1. Data Services Manager
현재 DSM은 VCF에 번들 공급할 뿐, 기본 배포 구성에서 제외하였다. VCF 9 카탈로그로 미뤄볼 때 차기 버전에서 통합될 것으로 예측하였다.
DSM은 OSS를 사용하며 동시에 서비스한다.
-
기 구축한 OSS와 연결하여 데이터베이스 관리 정보 저장
-
기 구축한 OSS와 연결하여 데이터베이스 백업/복원
-
MinIO AIStor 라이선스 통한 vCenter 통합[9]
2.4. 보안
클라우드 서비스 운영은 인프라스트럭처 보안은 물론 신원 및 접근 관리에 대한 기본 설계를 요한다.
2.4.1. 인프라스트럭처 보안
기존의 vSphere 환경 설계 및 구현 시에 익숙한 요소이다.
-
추상화를 통한 격리
-
네트워크 격리 및 네트워크 트래픽 제어
-
통신 암호화
추상화를 통한 격리
가상화 기술의 기본 보안 요소로서, VCF 솔루션을 도입하여 기본 충족한다 볼 수 있으나, 보안 규정 수준에 따라 Trusted Platform Module (TPM) 기술을 활용한 VM 키 관리와 스토리지 퍼포먼스의 균형을 고려하여 하드웨어 추가 설계를 고려한다.
네트워크 격리 및 네트워크 트래픽 제어
네트워크 격리는 VLAN을 사용하여 구현하는 네트워크 간섭 사고 및 공격을 방지하기 위한 기본 격리 시나리오이다.
-
하이퍼바이저 네트워크
-
관리 네트워크
-
vMotion 네트워크
-
Overlay Tunnel End Point (TEP) 네트워크
-
Intelligent Platform Management Interface (IPMI) 네트워크
-
백업 네트워크
-
기타
네트워크 트래픽 제어는 규정을 준수하는 각 네트워크와 어떠한 수단을 통하여 어느 정도 통신할 지에 대한 이중화 시나리오이다.
-
물리 네트워크 인터페이스 카드 (pNIC)
-
가상화 스위치 포트 그룹
-
Quality of Service (QoS)
pNIC의 필요 수량에 따라 x86 서버의 프로세서 다중화 및 유닛 크기에 영향을 미치므로 공급하는 하이퍼바이저 설계와 병행해야 한다.
통신 암호화
SSL/TLS 인증서는 서버와 클라이언트 간의 통신에 비밀을 보장하고 감청을 방지하는 종단 간 암호화 기술이다.
SSL/TLS 인증서 발행처를 인증 기관 (CA)라 하며, 유형과 목적에 따라 나눌 수 있다.
SSL/TLS 인증서를 통한 통신 암호화는 기본 업무 절차 중 하나이다. CA는 가능한 한 통일해야 한다. 전체 인프라스트럭처 및 애플리케이션에 걸쳐 신뢰 등록해야 할 인증서를 줄이기 위함이다.
또한 SSL/TLS 인증서는 암호화 사설 키의 유출을 고려하여 발급 시의 이용 기한이 정해져 있다. 인증 기한 도달 전 교체하지 않으면 통신이 정지하며 업무의 정지를 유발한다.
이를 해결하기 위해 인프라스트럭처 관리 조직은 Root CA를 만들고 인증서 발급을 중앙 관리하도록 해야 하며, 보안 규정 요소에 따라 중간 인증 기관 (Intermediate CA)을 통해 유연한 SSL/TLS 인증서 발급 및 관리를 구현하도록 설계해야 한다.
통신 암호화는 네트워크 격리와 함께 VCF 배포 전에 고려해야할 사안 중 하나이다.
| SSL/TLS 인증서의 유효 기간 국제 표준은 지속 짧아지고 있으며, 자동화를 권장하고 있다. 2029년까지 49일 단위 재발급을 구현해야 한다. Apple의 경우, 서버 인증서가 표준 기한을 지키지 않으면 OS가 앱을 일시 정지한다. [11] CA의 루트 인증서가 신뢰 상태여도 발생하며, 이러한 표준을 지키지 않은 모든 서버 인증서를 서비스 이용자가 직접 개별 허용해야한다. |
|
Public CA 및 Private CA
Public CA는 국제 기관 및 기업간 조율에 의해 신용하기로 결정하여, 이들의 인증서는 컴퓨터 운영체제 또는 웹 브라우저에 기본 포함한다.
Private CA는 누구나 직접 SSL/TLS 인증서를 발행하고 암호화 키를 관리할 수 있는 OpenSSL기술을 활용한 사설 CA를 뜻한다.
|
|
Root CA 및 Intermediate CA
Root CA는 최초의 CA이며, Intermediate CA는 Root CA로부터 SSL 인증서를 발급할 권한을 부여받은 2차 CA다.
|
vCenter Server Appliance
vCenter 기본 배포 시, Root CA인 VMware Certificate Authority (VMCA)를 생성하며며 크게 두 목적을 위해 CA를 사용한다.
-
vSphere Client 및 VMware Remote Console 등 VI Admin 접근을 위한 HTML 및 API 통신
-
하이퍼바이저 중앙 관리 통신 (vCenter Security Token Service)
SDDC Manager
SDDC Manager 배포 후, VCF 솔루션의 SSL/TLS 인증서 통합을 위한 Private CA를 생성하거나, Active Directory Certificate Services (ADCS)에 인증서 요청 및 발급을 통합할 수 있다.
CA 트리 시나리오
조직의 인증서 관리 규정을 일괄 적용해야할 경우에는 vCenter STS의 인증서를 중간 인증 기관 CA로 교체하여 관리하도록 구성한다.
| VMware by Broadcom은 vCenter Server STS 인증서의 교체를 지양하도록 권고한다.[12] |
일반 배포 시나리오이며, vCenter Server STS 인증서만 vCenter가 관리하도록 두고, vSphere Client의 SSL/TLS 인증서만 통합한다.
2.4.2. 신원 관리
통신 암호화 고려와 함께, 추후의 클라우드 인프라스트럭처 신원 관리를 고려한다.
Open Source를 활용할 경우, 다양한 소프트웨어를 통해 직접 구현할 수 있다. 예를 들면 하기와 같다.
-
LDAP: OpenLDAP (LightLDAP 비권장)
-
CA: OpenSSL
-
OIDC: Authentik, Apache Keycloak or et cetera
VMware가 지원하는 Microsoft Active Directory 사용 시, 하기의 기능을 통해 구현할 수 있다.
-
LDAP: Active Directory Domain Services
-
CA: Active Directory Certificate Services
-
OIDC: Active DIrectory Federation Services
LDAP
LDAP은 관문을 담당하는 공통 인프라스트럭처에서 구현하여 조직에 디렉터리 서비스를 제공한다.
클라우드 서비스 인프라스트럭처의 경우, 별도 구축 없이 지원 인프라트럭처에 아웃바운드 접근하여 LDAP 신원 및 접근 관리를 수행한다.
OIDC Single Sign-On
현대 웹앱 서비스에 신원 및 접근 관리로 역할 기반 접근 통제 (Role based Access Control, RBAC)를 구현할 때는 LDAP을 넘어서 OAuth 2.0을 적용한 OpenID Connect (OIDC) 기술이 널리 쓰인다. Aria Suite Lifecycle에 포함된 Identity Manager (Identity Manager) 또한 이런 기술을 접목하기 위해 제작되었다.
그러나 Identity Manager의 용도와 활용에 대해 고민해야 한다.
-
Identity Manager의 제작 목적이 인프라스트럭처 관점의 VMware Cloud Management Portal (CMP) 관리에 초점이 맞추어 있는 점
-
End User Computing Division의 분사 (Omnissa)로 인해 Identity Manager를 대체하는 새 소프트웨어의 개발이 필요한 점
그런므로 OIDC 또한 관문을 담당하는 공통 인프라스트럭처에서 별도로 구현하여 조직에 통합 서비스를 제공토록 한다.
3. 클라우드 서비스 인프라스트럭처
3.1. 병합 아키텍처 모델
VCF 솔루션의 자원 사용 단위는 셋으로 구분한다. 병합 아키텍처 모델은 이러한 자원 할당을 클러스터 내 자원 풀로 구분하여 통제한다.
EVCS는 보다 폭 넓은 파트너 및 국내 환경을 고려하여 병합 클러스터 (consolidated cluster) 아키텍처를 골자로 하였다.
-
VCF 솔루션 관리
-
워크로드
-
NSX Edge
최초의 VCF 데이터 센터는 병합 클러스터로 설계하고, 워크로드 클러스터 등을 추가하여 서비스의 안정성을 확장하는 방향으로 운영한다.
3.2. 동서 트래픽
3.2.1. Multitenancy
클라우드 이용자에게 고유한 서비스 영역 가치를 전달하려면 멀티테넌시가 필수이며, NSX가 서비스를 제공한다. VCF에서 NSX를 사용하여 멀티테넌시를 구현하는 방법론은 크게 두 가지이다.
NSX Virtual Private Cloud
NSX Virtual Private Cloud (VPC)는 프로젝트 단위의 테넌트 정의를 제공한다. VCF의 최신화 멀티테넌시 모델이다.
기본 NSX 인프라스터럭처의 복잡성을 숨김으로서 퍼블릭 클라우드 환경과 유사한 간소화된 네트워킹 및 보안 서비스 소비 모델을 제공한다.
Virtual Private Zone
Virtual Private Zone (VPZ)는 VCF Automation에서 테넌트 정의를 제공한다. vRealize Automation부터 이어진 멀티테넌시 모델이다. VCF Automation VPZ는 Automation Assembler 사용하여 이미지 및 플레이버 매핑을 구성할 때 멀티테넌시를 제공한다.
EVCS 5.2 및 Orbirum은 VCF Automtion VPZ를 사용하며, 클라우드 서비스 구현 시, 용어를 VPC로 통일한다.
| vRealize Automation VPZ와 혼용할 수 있지만 구성을 변경할 수 없으므로 VCF Automation VPZ과의 클라우드 서비스 구현 호환성을 고려해야 한다. |
3.2.2. NSX Overlay Transport network
NSX Manager 및 오버레이 전송 네트워크는 VCF 최초 배포 시에 함께 펼치므로, 배포 전 패브릭을 설계한다. TEP 네트워크와 호스트는 고유한 VLAN과 아이피를 할당한다.
